IBIS Macromodel Task Group Meeting date: 12 February 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Randy to investigate if/why/how a clock waveform input might be used. - In progress. Justin noted that this is worth exploring based on some of the DesignCon IBIS Summit presentations. - Michael M. to investigate if/why/how a clock waveform input might be used. - In progress. - Michael M. to check with IP experts on whether DC_Offset is useful for Tx. - In progress. - Randy to submit BIRD197.2 to the Open Forum. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 15 meeting. Mike L. moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: No one had anything new to discuss for the current agenda topics. IBIS-AMI Post Simulation Processing (FEC): (from the Topic bin list) Mike L. raised this topic. He asked how people feel about the idea that an AMI model, in addition to providing services for simulation, could also have a function that takes simulation results and settings and generates some final post-processed output (e.g., html report). He noted that one controversial aspect of the proposal was that the model might be doing something that is normally in the domain of the EDA too. For instance, the model maker might include compliance reporting for a particular version of a standard that the model supports. Walter rephrased the proposal as: Could we add some function to the .dll that is called just before AMI_Close(), and it would handle this special reporting? Mike L. agreed that was an accurate representation of the question/proposal. Walter noted that the AMI_Close() function itself is passed the memory handle and conceivably knows everything about the simulation. So, the model maker could simply have AMI_Close() generate any special reporting. That is, without any change to the IBIS spec, the model maker is already free to put anything they want into AMI_Close(). Mike agreed this was true, but suggested we might at least add a Reserved parameter to tell the user this extra reporting was provided. Walter felt this was unnecessary, as we already have DLL_ID that provides a unique name to every instance, and the model maker could add a Model Specific "generate_report" parameter if they wanted to. Arpad noted that each time this topic came up in the past the answer was always, "No, we don't need to do anything in the spec." However, the topic keeps being raised. Arpad said maybe the broader discussion topic is whether IBIS is just a modeling spec or whether it also does more things like post processing and compliance evaluation. Walter noted that in practice many IBIS parameters that were intended for use modeling the way the silicon actually works are just filled in with values for spec compliance. For example, Vinl and Vinh should be a way to specify when your device transitions, but in practice the values provided by model makers in Vinl and Vinh are often from a particular standard's compliance data. Values are often injected into models because of compliance rules. Arpad asked if we could continue to stay silent on this topic. Mike said that in theory the model maker could already do everything in AMI_Close(). He noted that he felt this topic could be removed from this list if it had not gained any traction at this point. Bob said he was neutral on whether to remove the topic, but he noted that it originated based on some FEC proposals by ZTE and Huawei. Mike recalled that 4 summit presentations had been given (several years ago), and two had specifically suggested that IBIS should do something about FEC. Walter had noted at that time that FEC was at a different layer than IBIS is typically used to model. Arpad said we might need to reach out to the authors for more specific proposals, or at least a high-level block diagram of what they had in mind. Mike L. took the AR to reach out to various summit presentation authors to see if they could provide more input. Power-Aware vs. AMI models: (Topic bin list) Mike L. noted that Ted Mido had presented his paper on his approach 3 times now. He asked if it would be up to Ted to partner with someone and write a BIRD. Arpad asked if everything Ted had presented could be handled without any changes to the spec (no new flows, no new parameters, etc.) Walter and Ambrish noted that they weren't sure how someone would do power-aware AMI when AMI assumes you have one IR computed at the beginning of the simulation. Walter noted that nothing could be done in AMI_Init(). Perhaps in the time domain GetWave() flow the tool could use sinusoidal power scaling or something else when it prepares the input waveform for the Rx GetWave(). This might not be a spec change, but it would be a flow change since the tool is doing something other than merely convolving the IR with the stimulus. Arpad noted that Ted's approach was different, and he was converting power fluctuations of the analog buffer model into a jitter distribution type value. To account for that additional jitter introduced by the power fluctuations, would we need to add any new parameters? Walter noted that a power-aware model could change the amplitude of the waveform but could also include a spectral density of the jitter. Perhaps we would need a new parameter (e.g. Tx_spectral_table or Rx_spectral_table) to point to a file containing the spectral density information. He noted that this sort of spectral density information probably couldn't be folded into one of the existing single-valued jitter params. Arpad asked if anyone wanted to start such a BIRD. Walter said that he didn't think we should unless/until someone came to us with a request. Mike noted that what Ted had presented was largely a flow. We would probably need to understand more fully exactly what flow he had used and whether IBIS could add something to help. - Mike L.: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Mike L. to reach out to FEC presentation authors for more information. ------------- Next meeting: 19 February 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives